Architecture for network manager

ABSTRACT

A distributed network management architecture, where a plurality of network managers share information about network elements by building the necessary infrastructure to discover alternate routes to element controllers when possible. A large number of network elements and operation controllers or managed object agents spans are simultaneously accessible to multiple graphical network browser instances on physical workstations. Each network manager can manage an element controller directly, through a direct connection, or indirectly, through an indirect connection to a second network manager which directly manages that element controller. As well, a plurality of telecommunication networks can be federated for transparently increasing the number of users and the reliability of each network. By allowing each network manager to be configured individually, more flexibility over both engineering and survivability is achieved.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention is directed to a network architecture and moreparticularly to a distributed network management architecture sharinginformation about network elements and providing increasedsurvivability.

2. Background Art

Network management has become increasingly complex in today'stelecommunications networks. Currently, network managers directlymanaged element controllers, which could be operation controllers (OPCs)or managed object agents (MOAs). Intelligent network elements (NE) aresoftware driven in every aspect from maintenance to control, to releaseupgrades. The management of these NEs requires a robust and highlyefficient system which can process a large volume of data over ageographically distributed network. This highly efficient system mustalso provide network management tools for simplifying day to dayoperations and reduce service down-time.

In the current network architecture, a network manager (NM) generallymanages a maximum number of 75 element controller pairs, an elementcontroller supports up to four NMs, and an OPC can control up to 1200network elements or networks. In addition, OPCs are limited processorsthat cannot handle more than four connections.

As customer transmission networks grow, so does the demand for thenumber of users who need access to the system. As such, the number ofNEs becomes larger and they are more geographically dispersed. All thesechanges cause significant technological challenges to the nature ofnetwork management. No longer can the entire customer network be managedcentrally from a single point, rather the need for distributed networkmanagement, locally and geographically, is a growing requirement.Additionally, customers wish to divide their network into differentregions based on political or business boundaries. Quite frequently twoor more regions overlap, presenting a challenge given the currentengineering limits.

U.S. Pat. No. 5,375,199 (Harrow et al. issued on Dec. 20, 1994 toDigital Equipment Corporation) discloses a method and device formonitoring performance of a computer system, including a graphical userinterface (GUI). The GUI is designed to provide historical or real timeinformation on the system and also allows the user to interact with theinformation being viewed.

U.S. Pat. No. 5,261,044 (Dev et al. issued on Nov. 9, 1993 to CabletronSystems, Inc.) relates to a network management system which performsfault isolation. The information relating to the network is displayed,the network entities being represented by icons. The user may select aprescribed area of an icon to obtain details regarding a particularaspect of the network entity represented by the respective icon.

However, these patents are not concerned with a distributed networkmanagement architecture designed for sharing information about thenetwork elements and for allowing each NM to be re/configuredindividually to manage the element controllers on a per span basis.

SUMMARY OF THE INVENTION

An object of this invention is to provide an architecture and corenetwork manager changes that allow a large number of network elementsand operation controllers (OPCs), or managed object agents (MOAs) spansto be simultaneously accessible to multiple graphical network browser(GNB) instances on physical workstations.

It is another object of this invention to provide an increasedsurvivability of network to network manager workstation communication incase of network outages, by building the necessary infrastructure todiscover alternate routes to controllers when possible.

Accordingly, the invention comprises a method of managing an elementcontroller of a telecommunication network using a plurality of federatednetwork managers (NM), comprising the steps of connecting a firstnetwork manager (NM₁) to the element controller (EC) for directlymanaging the EC, and connecting a second network manager (NM₂) to theNM₁ for indirectly managing the EC.

The invention further comprises a method of federating a plurality oftelecommunication networks for transparently increasing the number ofusers and the reliability of each network, comprising the steps ofdirectly connecting a first network manager (NM₁) to a first group ofECs, and connecting a second network manager (NM₂) to a second group ofECs for direct management of the respective first and second group ofECs, providing at each ECs of the first group a collector name serverwith information on the NM₁ and any other NMs directly managing thefirst group, and providing at each EC of the second group a collectorname server with information on the NM₂ and any other NM directlymanaging the second group, establishing a connection between the NM₂ andthe NM₁, upon a connection request from the NM₂ to a first EC of thefirst group, establishing an indirect connection between the NM₂ and thefirst EC for indirect management of the first EC through the NM₁, andupon a connection request from NM₁ to a second EC of the second group,establishing an indirect connection between the NM₁ and the second ECfor indirect management of the second EC through the NM₂.

The invention also pertains to a method of federating a plurality oftelecommunication networks for transparently increasing the number ofusers and the reliability of each network, comprising the steps ofdirectly connecting a first network manager (NM₁) to a first group ofECs, and connecting a second network manager (NM₂) to a second group ofECs for direct management of the respective first and second group ofECs, providing additional direct connections between the NM₁ andselected ECs of the second group, and providing additional directconnections between the NM₂ and selected ECs of the first group, andproviding at each ECs of the first group a collector name server withinformation on the NM₁ and any other NMs directly managing the firstgroup, and providing at the EC of the second group a collector nameserver with information on the NM₂ and any other NM directly managingthe second group.

Advantageously, NMs are configured to directly or indirectly manageelement controllers on a per span basis. Indirect management allows thenetwork manager user to specify the preferred method of managing thecontroller, reducing the total number of direct connections to an OPC,while giving more network managers visibility of the network.

Another advantage of the architecture according to the invention isself-healing, whereby a NM seeks other NMs to federate to, or promotesitself to direct management, when a NM directly managing an elementcontroller fails.

Scalability and survivability together mean increased numbers of usersin a variety of locations, managing a larger number of network elementstransparently and with higher reliability. Some element controllers aremanaged directly and even more, indirectly. Thus, the networkarchitecture according to the invention allows management of up to tenthousand NEs, and up to seven hundred and fifty element controllersspans are simultaneously accessible.

Still another advantage of the invention is that by allowing eachnetwork manager to be configured individually, more flexibility overboth engineering and survivability is achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescription of the preferred embodiments, as illustrated in the appendeddrawings, where:

FIG. 1 illustrates a network architecture with indirect and directmanagement of element controllers;

FIG. 2 shows the increase in user capacity aspect of scalabilityaccording to this invention;

FIG. 3 illustrate survivability scenarios: FIG. 3A shows the points ofconnectivity loss, FIG. 3B shows how management of an element controlleris effected by an alternative network manager (NM) in case ofconnectivity loss, and FIG. 3C illustrates a reluctantly promotedmanagement path;

FIG. 4A shows an exemplary network extending over two regions;

FIG. 4B shows a first phase in the network growth comprising a networkoperation centre;

FIG. 4C shows a second phase with an alternative network operationcentre for survivability;

FIG. 5A illustrates an example of evolution of the network architectureof FIG. 4A, using indirect and direct management;

FIG. 5B illustrates a further evolutionary stage of the network of FIG.5A using a federated connection between regional network managers,together with indirect and direct management;

FIG. 6A shows the evolution of network of FIG. 5B, with networkoperation centers, federated, direct and indirect connections;

FIG. 6B shows the architecture of FIG. 6A, indirect connections removed;

FIG. 7 shows one possible reconfiguration of the network of FIG. 6A incase of failure of a regional network manager;

FIG. 8 shows how the number of users of configuration shown in FIG. 6Bmay be increased using scalability;

FIG. 9 illustrates a further evolutionary stage for the network of FIG.6, designed for increased survivability;

FIG. 10 shows the main components of the network manager and the elementcontroller for implementing the architecture of the invention;

FIG. 11 is a flow-chart for operation of the network to establish anindirect connection between a NM and an element controller; and

FIG. 12 is flow-chart showing the operation of the network tore-establish a direct connection between a NM and an element controller.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Definitions of some terms used in this specification are provided next,for a better understanding of the invention.

A network manager consolidates the OAM&P information collected from thecontrollers in the network. An element controller, which could be anoperation controller (OPC) or a managed object agent (MOA), manages aspan, or sub-network of NEs, providing functions to, and collectinginformation from the NEs within the span.

Scalability is defined herein as the ability to configure multiplenetwork managers in such a way that they can share information aboutNEs, thereby increasing the number of NEs each network manager canmanage without increasing the demands on the element controllers.Network managers configured in such a manner are called federatednetwork managers, and as a whole, they are called a federation ofnetwork managers.

Scalability introduces the concept of indirect management of elementcontrollers via another network manager. FIG. 1 illustrates theprinciple of direct and indirect management according to this invention.A first network manager 1 directly manages OPCs (operation controller)2. This is shown by direct management path (connection) 3. A secondnetwork manager 4 manages OPC 2 indirectly, as shown by indirectmanagement path (connection) 5, via a federated connection 6 to networkmanager 1. The direct connections are illustrated throughout thedrawings in solid lines, indirect connections are illustrated in dottedlines, and the federated connections, in double lines.

The number of element controllers that can be indirectly managed islarger than the number of element controllers that can be directlymanaged, thereby increasing the total number of network elements thenetwork manager can manage. Conversely, there is no restriction on thenumber of network managers that indirectly manage an element controller.This is shown in FIG. 2, illustrating OPC 2 managed through directmanagement paths by four direct NMs 1, each direct NM 1 (D-NM) beingconnected to 24 indirect NMs 4. In this way, each indirect NM 4 (I-NM)can indirectly manage OPC 2, resulting in a network architecture whichallows management of up to ten thousand NEs, up to seven hundred andfifty element controllers spans being simultaneously accessible.

It is to be noted that a network manager acts as an indirect manager fora controller in a federation, if and only if, it is directly connectedto a direct manager of that controller.

There is more to scalability than just sharing of information,scalability also provides a mechanism for increased survivability.Survivability is the ability for a federation of network managers toheal itself when there is a failure in the underlying transmissioncontrol protocol/internet protocol (TCP/IP) layer or in one or more ofthe network managers.

FIG. 3A shows a simple network and two points of connectivity loss, foran exemplary network comprising NMs 1 and 8 directly managing OPC 2 anda third NM 4, indirectly managing OPC 2 through NM1. A firstsurvivability scenarios disclosed in for an interruption of themanagement path 3 between OPC 2 and NM 1, a second scenario is disclosedfor both an interruption of the, management paths 3 and management path7 between OPC 2 and a NM 8.

In the case of the 1st scenario, (NM) 4 cannot manage any more OPC 2indirectly through NM 1, and it looks for an alternative managementpath. As NM 4 is federated with NM 8 over federated connection 9, NM 4detects this alternative NM 8 and re-establishes an indirect managementpath to OPC 2 through NM 8, as shown in FIG. 3B,

As indicated above, NM 4 has a preferred indirect connection to OPC 2.However, if both management paths 3 and 7 are interrupted, (secondscenario), NM 4 cannot indirectly manage OPC 2. Now, NM 4 is forced toestablish a direct connection because of the lack of an indirectconnection. This connection is termed a direct reluctantly promotedconnection. This connection/state is considered transitory, and NM 4will attempt to restore back to indirect management at the firstavailable opportunity. This scenario is illustrated in FIG. 3C, where NM4 promoted itself to directly manage OPC 2 through a reluctantlypromoted management path 10.

FIGS. 4A to 7 show examples on how a network evolves as the number ofthe subscribers grows and as the user's requirements change. Thesescenarios also depict one way the phased delivery of scalabilityfunctionality could impact the evolution of network management in acompany.

Let's assume that the size of the initial network has recently grownsuch that a network provider (NP) can no longer manage the entirenetwork from a single network manager. When this point was reached, theresponsibility for the network is divided between two regions, Easternand Western regions, as shown in FIG. 6A.

As well, let's assume that the Western region is expected to grow morein the near future, so the provider planned ahead and deployed twonetwork managers 30 an 40 at the Western region control center (RCC) 50.

Each network manager directly manages a number of operation controllers31, 33, 35, 37, 39, 41, 43, 45, 47, and 49. The description and drawingsrefer to OPCs for simplification, but it is to be understood that theinvention applies also to other element controllers. The OPCs aredeployed as necessary at various sites in the Western and Easternregion. FIG. 6A also shows that some OPCs are managed by two networkmanagers, for reasons that will be explained later. Thus, OPCs 35 and 37are monitored by both network manager 30 and network manager 40, OPCs 41are monitored by network manager 40 in the Western region and networkmanager 60 in the Eastern region.

The explosive growth of the network of FIG. 4A has led NP to realizethat a network operations center (NOC) 70 need to be created formonitoring the entire network via direct connections 71, as shown inFIG. 4B for the second phase of growth (NOC is also a NM). The regionalnetwork managers 30, 40 and 60 still exist for the day-to-day running ofthe network, while the NOC 70 is primarily used for off-hours supportand demos to customers.

As each controller can be directly managed by maximum two networkmanagers in the phase shown in FIG. 4A, NP realizes that the number ofconnections per OPC must be increased from two to four for allowing moreconnections per OPC and more OPCs per network manager, for somecontrollers, such as OPC 35, 37 and 41 which each need three connectionsto them.

However, the solution of FIG. 4B is temporary, for as soon as the numberof OPCs in the network outstrips the maximum number that can bemonitored from the network manager in the NOC, NOC 70 can no longermonitor the entire network. Increasing the number of element controllerconnections does nothing to enhance survivability, except increase thenumber of workstations that can monitor the network.

In addition, the site for NOC 70 can be a dangerous place, subject toearthquakes, volcanoes, power outages and crime. NP is concerned aboutsurvivability of the network and has built an alternative NOC 80 at adifferent site, to take over in disaster scenarios, as shown in FIG. 4C.Additionally, the alternative NOC 80 can be used to off-load NOC 70during peak demand and holidays. Unfortunately, by providing alternativeNOC 80, provision of direct connections 81 to the OPCs exhausts thecurrent maximum number of connections (four) for OPCs 35, 37, and 41.

Also, it is not possible to increase the number of the OPCs in thenetwork of FIG. 4B, since additional OPCs cannot be managed by NOC 70,the current engineering limit being 150 OPCs for a NOC, or 75 OPC pairs.As well, if for some reason, more network managers were required tomonitor controllers 35, 37, and 41, this would be possible only usingindirect management.

Not taking the NOCs into consideration just yet, indirect elementcontroller management allows a reduction in the number of connectionsused at the sub-network controlling devices, as seen in FIG. 5A. Thenumber of direct connections in group 51 and group 53 has been reducedfrom four to three by implementation of indirect connections 63 and 65.For implementing the indirect connections, a federated connection 61 hasbeen set between NM 30 and 40. No changes have been made to the OPCsthat each network manager directly manages, NM 30, 40 and 60 see thesame controllers as before indirect management.

Next phase of growth provides for expanding the controllers managed bynetwork manager 30 to include OPCs 37, 39 and 41, namely all OPCs in theWestern region, as shown in FIG. 5B. This was done by increasing thenumber of indirect connections in group 63 from one to three. Similarly,the OPCs managed by NM 40 include now all of the OPCs in the Westernregion, by increasing the number of indirect connections in group 65from one to three. By indirectly connecting to OPCs 31, 33 and 35, moreusers have visibility of all of the NEs in the Western region.

In the next phase of network growth, NOCs 70 and 80 are given a view ofthe entire network by federating each network operating center with theregional network managers 30, 40 and 60, as shown in FIG. 6A. Thisimplies providing federated connections 73, 74 and 76 for connecting NOC70 with regional network managers 30, 40, and 60, and federatedconnections 83, 84 and 86 respectively, for connecting NOC 80 withregional network managers 30, 40, and 60. Indirect connection 63 and 65are configured as in the embodiment of FIG. 5A. NOCs 70 and 80 do notdirectly manage any controllers, rather they manage all of the OPCsindirectly via the regional network managers. Implementing this is easyas it is simply a case of changing the existing direct connections tothe OPCs, as shown in FIG. 4C, into indirect connections.

A much cleaner picture of the connections in the network is shown inFIG. 6B, which is FIG. 6A with the indirect connections removed. Inreality, the indirect connections are only logical connections, nosurveillance or status information flows along these connections.

Unfortunately, it is not clear from FIG. 6B the OPCs that each networkmanager indirectly manages. This is not important from a users' point ofview, but from an engineering point of view, this picture clearlydepicts the “nailed up” connections between the OPCs and the networkmanagers, and the federated connections between the network managers.

Regarding how survivable this configuration actually is, let's assumethat, for example, NM 60 is accidentally turned off. Now, NOCs 70 and 80cannot indirectly manage the OPCs 41, 43, 45, 47, and 49 in the EasternRegion, and some form of direct management must be provided. Onepossible reconfiguration is shown in FIG. 7, NM 60 with its directconnections is not shown for simplification and also because is notturned on. Controllers at 47 are now directly managed by NOC 70, andcontrollers at 43, 45 and 49 are directly managed by NOC 80. NOCs 70 and80 have created a federated connection 78 between them so that they canindirectly manage the OPCs the other is directly managing.

In general, the sharing of the load of managing the OPCs must notnecessarily be divided equally between the network managers. In thefirst phase of scalability, indirect connections should be attemptedfirst to the network manager whose address is defined in a preferencefile, or lacking that, if sub-networks are implemented, to a workstationon the same sub-network as the indirect client. Either way, the numberof simultaneous users of the NOC at each site has grown to exceed themaximum supported by a single workstation. However, using scalability,it is a simple case to add another workstation in the site of, forexample NOC 70, to allow more users, as shown in FIG. 8.

All of the OPCs of FIG. 8, but OPC 41, now only have one connection tothem, even though most of them have four network managers managing them.The addition of a third NOC 90, would not change these numbers.Additional connections to OPCs are now no longer required to getvisibility from different network managers, rather the additionalconnections are used to engineer better survivability configurations orto restrict access for whatever reasons.

Self-healing requires a NM to seek out other NMs to federate to, or inthe worst case, a network manager has to resort to directly managing thecontroller. Finding another network manager to federate to is the idealself-healing process, because the healing process is quite short, andtherefore configuring the network to try and take advantage of this ishighly desirable. One way to facilitate this objective is to havemultiple network managers directly managing each OPC, so that federatednetwork managers can quickly re-establish indirect connections.Eliminating single-points of failure is the primary goal. Ideally, thenetwork managers directly managing each OPC should be connected viadifferent routes and should be geographically separated to eliminate thechance of environmental problems disabling both network managerssimultaneously.

The configuration of FIG. 8 is still asymmetric in that the regionalnetwork managers still do not manage OPCs outside of their region. Theresulting configuration is shown in FIG. 9. On the other hand, whileadding multiple direct connections in one federation potentiallyincreases the recovery time in the case of a failure (it is assumed thatinitializing through a federated workstation will be quicker thanconnections to an OPC directly), the total number of controllers thatcan be managed across the federation will be decreased, as theengineering limits will strictly enforce the total number of directconnections per network manager.

Taking all this into account NP decided to increase the responsibilityof the NOC workstations so that they share in the management of thecontrollers, as shown in FIG. 9.

There are now multiple routes for a network manager to indirectly managean OPC. For example, network manager 70 could monitor OPCs 49 viafederated connection 76 to network manager 60, and the respective directconnection of group 55, or via federated connection 78 to networkmanager 80, and direct connection 88. Both routes directly manage OPCs49.

The responsibility of each regional network manager is wisely split inthe configuration of FIG. 9, so that the effort is shared when aregional network manager is off-line. Thus, if network manager 70 wereindirectly managing OPC 49 via network manager 60 and network manager 60lost power, network manager 70 would switch to indirect management vianetwork manager 80. If network manager 80 were indirectly managing OPC41 via network manager 60, and network manager 60 lost power, networkmanager 80 would switch to indirect management via network manager 40.If network manager 70 were indirectly managing OPC 45 via networkmanager 80, the failure of network manager 60 would have no impact.

If subsequently network manager 40 failed, there would no longer be anynetwork managers directly managing the OPCs 41 and one of networkmanagers 30, 70, or 80 would have to directly manage OPCs at 41. Forexample, network manager 30 could reluctantly promote itself to manageOPCs at 41, network managers 70 and 80 would then indirectly manage thisOPC via network manager 30. Similar recognition would occur for theother OPCs at 41 and the load of directly managing these orphanedcontrollers would be shared amongst the remaining network managers.

If NP wishes to enter a joint alliance with a long-distance provider LD,they must share management of a set of OPCs, let's say OPCs 41. Mostprobably, NP does not want LD to determine how the remaining of thenetwork is managed. Conversely, LD does not want NP to determine how itsnetwork is managed. The solution is to configure separate networks toterminate at the OPC, and each company to configure their networkmanager to directly manage the shared OPCs. This does not change the NPconfiguration of the network of FIG. 9 at all, except the number of freeconnections on each of the shared OPCs is reduced.

In the case of the multiple failure scenario above and shared OPCs at41, when network manager 40 failed, network manager 30 would attempt toconnect to the LD NOC 80. However, because the LD network manager is onanother network, there is no IP connectivity to this network manager andnetwork manager 30 is forced to resort to direct management of OPC 41,even though there is another network manager, namely NM 60, directlymanaging the OPC 41. Thus, configuring the IP network is important toprevent network manager 30 indirectly managing OPCs at 41 via the LDnetwork manager.

FIG. 10 shows the main components of a NM and an element controllerrelevant to this invention. Network manager 30 shown in FIG. 10 is aworkstation which provides nodal and sub-network OAM&P capabilitiesthrough a single view of transport and access nodes and directly managesa plurality of NEs that are connected to OPC 41. As indicated above, NM30 may also indirectly manage a plurality of OPCs and can act as aclient or server for other NMs.

NM 30 provides a graphical surveillance user interface (GUI) toolincluding a plurality of graphical network browsers (GNB) 12 and aconfiguration GUI named the graphical network editor (GNE) 14. Accordingto the invention, whether an element controller is directly orindirectly managed has no bearing on the performance or behaviour of theGNB 12 and is transparent to the GNB user.

Network managers are configured by the user via GNE 14 to directly orindirectly manage element controllers on a per span basis. Provisioningwhat controllers the network manager is interested in by specifyingtheir IP address, is done in the GNE 14 as usual. The fundamentaldifference is that the operator may now select the preferred managementpath, direct or indirect. To this end, GNE 14 selects the elementcontroller and the preferred management path, i.e. direct or indirect.An indirect server manager component (ISM) 34 and an indirect clientmanager component (ICM) 36 are the core of the scalability andsurvivability solution. These components are integrated into theexisting network manager collector process and provide the ability toservice incoming requests from other network managers as an indirectserver, and to similarly establish connections to other network managersas indirect clients.

ISM component 34 provides a mechanism to service indirect managementrequests from other network manager workstations. This is accomplishedby creating a TCP/IP server at a well known port for processing theincoming requests.

The information flow between NM 30 as a directly managing server and aclient NM is provided over a federation network interface (NNI) 32. Oncethe interface is negotiated, the indirect server 34 waits for requestsfrom the client NM for the specific OPC/MOA entities that the requesteris interested in. Only requests for controllers that are currently beingmanaged via a direct connection to the OPC or MOA such as OPC 41 will beconsidered by ISM 34.

When this negotiation is complete, information flow for the controllerpair is transmitted from ISM 34 to the indirect client NM. Only oneTCP/IP connection is maintained per communicating network managers. Thisinformation includes core network element information, such as nameidentifiers, rate, type and support information, existing active alarms,and asynchronously delivery alarm state transitions, performancemonitoring support information, sub-network configuration data, andnetwork element connectivity or association status.

The role of ICM 36 is to find a path to a controller if the managementpath is specified by GNE 14 as indirect. It does this by first queryingthat OPC for the list of currently connected network managers, thenattempting to register indirectly through another network manager. Ifthere are no direct managers available, ICM 36 will attempt toreluctantly promote itself to direct management of that controller.

When presented with a choice of two or more possible routes for indirectmanagement, ICM 36 will choose a preferred route according to apreference algorithm, if it is available. The preference algorithm usesan indirect access database (IAD) 38, and performs for example thefollowing operations:

First, IAD 38 is consulted by ICM 36 for the list of preferred paths. Ifthere is a match, that path is attempted first. For example, an entry inIAD 38 of form ‘47.105’ means that presented two possible indirect paths‘47.105.9.219” and ‘47.45.4.48’, ‘47.105.9.219’ will be selected first.

Next, if sub-networks are implemented, and if one of the routes is anetwork manager on the same sub-network as the client, that route isattempted first.

Last, a random selection is made if no preferred path resulted from theabove operations.

This strategy allows for an additional level of control over indirectmanagement, allowing optimal network paths (where there is morebandwidth, for example) to be established first, if available.

IAD 38 is also consulted by ICM 36 before allowing access to an indirectmanager client. This database comprises of a list of IP addresses orsub-networks that requests will or will not be accepted from. This isused to facilitate the creation of independent federations which do notshare management information or interact with each other. It is alsoused to ensure a predictable environment during software testing. Thedatabase 38 is modifiable using a simple configuration tool accessiblefrom the existing administration tools.

The effect of increasing the total number of NEs impacts on the totalamount of network configuration data that must be stored, includingactive alarms for the entire network. This requirement places additionalburden on the NM physical resources. The underlying assumption inevaluating the impact on NM, however, is that only a relatively smallportion of that data will ever need to be duplicated through userinterfaces at any one given instance in time.

A network data cache (NDC) may be used in another embodiment of theinvention for managing and storing data previously shared by all GNB'sinto a single cache entity, available for reading by all network managerprocesses. NDC is used to write various data in a shared area to beaccessed in a read-only fashion by all other network manager processes.The goal of NDC is to achieve an order of magnitude savings as comparedto the existing GNB 12 and GNE 14 process under similar loadedconditions, thus minimizing or eliminating the requirement foradditional hardware to achieve the engineering limits.

A component of the architecture according to the invention isimplemented in the collector name server (CNS) 46 component provided ateach OPC/MOA workstation. CNS 46, whose interface is implemented throughthe existing regulation browser (REGB) process on the OPC, provides amechanism to query the OPC server for the existing directly connected NMworkstations, necessary for enabling ICM 36 to select a path forindirect management.

In the a preferred embodiment, access to the NE and OPC/MOA userinterface is accomplished by using the primary network manager collectorto controller interface to add entries in the appropriate control fileson the controller, which then allows the network manager unauthenticatedremote execution of selected processes, if a concurrent entry for theinvoking client UNIX userid is present on the controller.

As a design requirement, each indirect connection accounts for theequivalent of two directly managed element controller spans. Thisparameter is enforced and has been deduced by engineering studies on theexisting architecture. An interface is provided by ISM 36, to manage andkeep track of these indirect connections for the purpose of engineeringthe entire NM collector process. Specifically, because of thepossibility of a failure of one or more indirectly managing workstationscausing the client to attempt direct connections to the controller andpotentially well exceed its maximum number of direct connections, thisnumber in conjunction with the current number of primary and backupdirect connections may be used to enforce engineering limits in thesoftware.

Additional changes can be made to the existing components of the NM. Forexample messaging optimizations between GNB 12 and the components of theNM must be provided as a result of these changes. The controller listdialogue can also be substantially modified to accommodate the nowlarger volume of controllers, as well as reflect the routing decisionsbeing made by the network manager, such as IP address of network managerserving an indirect connection, indirect or direct preferred state, andthe current actual management state of each controller. This informationshould also be visible to GNB users in a read only fashion.

It is suggested that T1 or equivalent bandwidth as a minimal requirementto sustain acceptable performance between federated network managers.Given the basic data provided, the entire network bandwidth can beengineered to account for shifts in management responsibility that willhappen when survivability aspects are considered. Any extra bandwidthrequired to maintain acceptable performance when shifts in managementhappen will largely depend on how the federation is setup and how manyspans are being managed concurrently across the federated connections.

FIG. 11 illustrates how an indirect connection is established in thenetwork of FIG. 9. Let's suppose that NM 70 requests communication withOPC 41 as shown in step 100. NM 70 queries OPC 41 via CNS 46 regardingthe NM directly connected to this OPC, in step 110. If a plurality ofdirect NMs is found, such as NM 40 and NM 60 in step 120, a preferencealgorithm selects a preferred direct NM in steps 130-150.

When specifying a preferred direct connection, an attempt is made toregister directly with the element controller 41 as usual. If both NM 40and NM 60 failed, or none of NM 40 and NM 60 directly manage OPC 41, asillustrated along the NO branch in step 120, NM 70 would negotiate aself-promotion with the element controller to directly manage it, asshown in step 220. Information now flows between NM 70 and OPC 41, step230, and other network managers could then indirectly manage the elementcontroller 41 via this promoted network manager.

If the connection was established through a reluctantly promoted networkmanager, NM 70 will attempt to restore back to indirect management atthe first available opportunity, as shown by the timer in step 240.

As indicated earlier, if NM 40 and NM 60 are operational to directlymanage OPC 41, NM 70 must select one of these two NMs (i=1 or i=2) forindirectly managing OPC 41. The preference algorithm initiated in step130 is designed to take into account the network architecture and alsothe client's demands. In steps 140 and 150 NM 70 determines which one ofNM 60 and NM 40 has a preferred direct connection to OPC 41 andestablishes a management path to this preferred NM. If a preferreddirect connection is not available, as shown by branch ‘NO’ of block150, NM 70 determines which one of NM 60 and 40 has a preferredreluctantly promoted connection to OPC 41, as shown in steps 200 and210. Step 160 shows the flow of information between NM 70 and OPC 41,once a management path has been established in steps 130, 140, 150, 200,and 210.

Any changes in management path initiated under the control of thefederation will attempt to happen transparent to the GNB user, in otherwords without indicating a loss of connectivity for those networkelements affected (normally done by turning the affected icons blue).This is called a no-blue switch.

A direct benefit of scalability is the inherent survivability that comesfrom the distributed management of the network. Survivability isimplemented using a revertive N:1 strategy that allows multiple networkmanagers in the federation to maintain management of element controllerswhich can no longer be managed by another network manager for reasonssuch as workstation or network outages. This is accomplished by anindirect client, such as NM 70 in the example of FIG. 9, seeking outanother server, such as NM 60 in the federation, if its current serverbecomes unavailable, or if a controller becomes unavailable from thepoint of view of the current directly managing server. The NEs operateas in the case of establishing an indirect connection, shown in FIG. 11.

If a network manager workstation cannot directly manage an elementcontroller, it can no longer facilitate indirect management of thecontroller for federated network managers. Federated network managersthat used to indirectly manage that controller will now have to findalternate means of doing the management, directly or indirectly. As partof the self healing process, the affected network managers will firsttry to find another network manager directly managing the NE controllerand establish a federated connection to it for the purpose of indirectlymanaging that NE controller. In the above example, NM 40 will beselected by the preference algorithm in step 130.

FIG. 12 is flow-chart showing the operation of the network tore-establish a direct connection. In step 300 NM 70 requests a directconnection with OPC 47. If the registration to this OPC is full, i.e.the element controller already serves four NMs, as shown by the ‘YES’branch in step 310, the query is repeated at regular intervals of time,shown in step 320, until OPC 47 becomes available, shown by branch ‘NO’.In this case, information flows between NM 70 and OPC 47 along directconnection 77, as illustrated in step 330.

Any changes in management path that are initiated by a real loss ofconnectivity, such as an outage of the supporting indirect serverworkstation, or the lack of network connectivity to an OPC or MOAworkstation, will always be indicated to the user.

If a network manager preferred management route is direct, and it cannotestablish a direct connection because the controller registration isfull and all other connections are preferred direct, it will not demoteitself to indirect. It is the responsibility of the federation managerto configure the network with no more than the maximum number of directconnections supported for that controller.

Indirect management of an element controller does not mean IPconnectivity is no longer required between the network manager and theelement controller it manages indirectly. In fact, IP connectivity isrequired to set up indirect management in the first place. IPconnectivity is also required for on-demand functionality such as remotelogin, PM query, remote inventory, shelf level graphics, and electronicsoftware delivery. For increased survivability, IP connectivity isrequired to allow the network manager to directly manage the elementcontroller if for some reason it cannot find another network managerdirectly managing the specific device.

Next, some survivability scenarios are discussed for the configurationof FIG. 9.

In the event of a loss of connectivity between an indirect NM, let's sayNM 40 for OPC 33, and its client NM 80, the client will attempt toreconnect indirectly via another manager whose principally configured asa direct manager. This is accomplished by requesting the list ofconnected network managers from CNS 62 of OPC 33, and posting a requestto the preferred server.

If there are no direct managers available, for example NM 30 is turned“off”, NM 80 will attempt to reluctantly promote itself to directmanagement of OPC 33 if there are any connections available.

The role of ICM 38 continues after recovery by continuously attemptingto recover a connection via an indirect path. When a route becomesavailable, a switch over is completed without presenting a loss ofconnectivity to depending applications. By always attempting a return tothis steady state, some level of control over communicating entities ispreserved.

It is to be noted that this switch over may also impact otherworkstations in the federation, who may be managing indirectly via thereluctantly promoted path. The switch over is mandatory, although allattempts will be made to re-establish routes without presenting a lossof connectivity to the application.

In the event of a direct NM, such as NM 30 losing connectivity to anOPC/MOA, such as OPC 33, the indirect clients NM 70 and NM 80 will benotified. A client, say NM 80 will then attempt to connect to OPC/MOA 33and establish a connection via an alternate route, for example throughdirectly connected NM 70, hence surviving a connectivity problem due toa network outage that only affected its current indirect server. Ifthere is no TCP/IP connectivity between the indirect client workstationand the controller (i.e. the controller is down, or invisible due to thesame network outage), it will continue to attempt indirect connectionsuntil a path becomes available.

In the event of a network manager outage, it is possible for more thanone federated network manager to establish a direct reluctantly promotedconnection to the same controller. Because this may affect federationengineering, it is an undesirable state.

To overcome this state, reluctantly promoted connections in thefederation continuously attempt to demote themselves, although onereluctantly promoted direct connection must always remain to ensure oneserver is available for the federation.

Other specifications for the network managers that should be notedfollow.

If an optimal route is not available at the time of connection resultingin the selection of another path, the ICM will not revert once theoptimal path becomes available.

Also of note is that multiple Ethernet interfaces are not supported; ifa workstation is part of multiple sub-networks due to more than one LANinterface, the preferred path will only be discovered if this is truebecause of the first or default interface, as specified in the IP hostmap.

When specifying indirect management for a span which contains both aprimary and a backup controller, an attempt will be made to use the sameindirect server for both the primary and backup controllers. Otherwise,the connection path for each controller is determined separately, whichmay result in the primary and backup getting their managementinformation from different indirect servers, or even both or one of thepair reluctantly promoting itself to satisfy its desire to find a pathto that controller.

The architecture allows for the future evolution of the messaginginterface between the NM and the controller which will allow theindirect server to communicate addressing information about indirectclients to the controller, allowing the indirect clients to make loginrequests directly to the OPC or MOA.

Because of the increased amount of data required to setup a largefederation interested in most or all of each others directly managedspans, a tool could be provided to remotely retrieve the preferreddirectly managed spans of any network manager in the federation andapply any or all of those spans as preferred indirect in the localnetwork manager's domain.

Several areas of functional improvements are possible beyond the abovedescription, as the previously mentioned load balancing when surviving afailure. The load on each NM is defined by the number of controllers itdirectly manages. This is configured manually by the user in the GNE andcan be re-defined at any time, so that all NM directly manage their fairshare of OPCs.

In a true load balancing application, after a recovery has beencompleted, the network managers will communicate their current loads andhand-off direct management of element controllers to less heavily loadedworkstations until a uniform load is achieved. This hand-off should notimpact functionality and should be transparent to GNB users.

In indirect management there is no balancing, the load is distributedrandomly based on which network manager is the first to claim a directconnection to each OPC, influenced by the network topology and thedistribution of the network managers within that topology. It isanticipated that given the random nature of this algorithm, a uniformdistribution will be achieved.

While the invention has been described with reference to particularexample embodiments, further modifications and improvements which willoccur to those skilled in the art, may be made within the purview of theappended claims, without departing from the scope of the invention inits broader aspect.

We claim:
 1. A method of managing an element controller (EC) of acommunications network comprising a first network manager (NM1)logically connected to the EC via a direct management path for directmanagement of the EC by the NM1, the method comprising the steps of: a)dynamically selecting, from at least two management paths, a preferredmanagement path between a second network manager (NM2) and the EC; andb) establishing a logical connection between the NM2 and the EC over theselected preferred management path to enable management of the EC by theNM2.
 2. A method as claimed in claim 1, wherein the at least twomanagement paths comprise one or more of: an indirect management pathvia a federated connection between the NM2 and the NM1; and areluctantly promoted direct management path between the NM2 and the EC.3. A method as claimed in claim 2, wherein the step of dynamicallyselecting a preferred management path comprises the steps of, from theNM2: a) querying the EC to obtain information identifying the NM1; b)determining if the NM1 is directly managing the EC; c) if the NM1 isdirectly managing the EC, selecting the preferred management path as theindirect management path via the federated connection between the NM2and the NM1; d) if the NM1 is not directly managing the EC: i) assuminga reluctantly promoted state at the NM2 to enable direct management ofthe EC by the NM2; and ii) selecting the preferred management path asthe reluctantly promoted direct management path between the NM2 and theEC.
 4. A method as claimed in claim 3, further comprising, if the NM1 isnot directly managing the EC, the step of periodically attempting todemote the NM2 from the reluctantly promoted state.
 5. A method asclaimed in claim 4, wherein the step of periodically attempting todemote the NM2 comprises the steps of: a) periodically determining ifthe NM1 has recovered direct management of the EC; and b) when the NM1has recovered direct management of the EC: i) demoting the reluctantlypromoted state of the NM2; and ii) selecting the preferred managementpath as the indirect management path via the federated connectionbetween the NM2 and the NM1.
 6. A method as claimed in claim 2, wherein,when the preferred management path is the indirect management path via afederated connection, the step of establishing a logical connection overthe preferred management path comprises the steps of: a) establishingthe federated connection between the NM2 and the NM1, the NM2 acting asan indirect client for the NM1, and the NM1 acting as an indirect serverfor the NM2; and b) establishing a logical connection between the NM2and the EC through the NM1 using the federated connection.
 7. A methodas claimed in claim 3, wherein the step of querying the EC comprises thesteps of: a) sending a query message to the EC, and receiving a responsemessage from the EC containing information identifying each networkmanager logically connected to the EC over a direct management path; andb) selecting the information identifying the NM1 from among theinformation identifying each network manager logically connected to theEC over a direct management path.
 8. A method as claimed in claim 3,wherein the step of determining if the NM1 is available forcommunication with the EC comprises the steps of: a) sending aconnection request message to the NM1 and awaiting a response messagefrom the MN1; b) if the response message is received from the MN1,determining that the NM1 is available; and c) otherwise, determiningthat the NM1 is not available.
 9. A method of federating first andsecond communications networks comprising a respective plurality ofelement controllers (ECs) logically connected to a corresponding networkmanager (NM) over respective direct management paths for directmanagement of the EC's by the corresponding NM, the method comprisingthe steps of: a) dynamically selecting, from at least two managementpaths, a preferred management path between an element controller (EC2)of the second network and a network manager (NM1) of the first network;and b) establishing a logical connection between the NM1 and the EC2over the selected preferred management path, to enable management of theEC2 by the NM1.
 10. A method as claimed in claim 9, wherein the at leasttwo management paths comprise one or more of: an indirect managementpath via a federated connection between the NM1 and a network manager(NM2) of the second network logically connected to the EC2 over a directmanagement path; and a reluctantly promoted direct management pathbetween the NM1 and the EC2.
 11. A method as claimed in claim 10,wherein the step of dynamically selecting a preferred management pathcomprises the steps of, from the NM1: a) querying the EC2 to obtaininformation identifying the NM2; b) determining if the NM2 is directlymanaging the EC2; c) if the NM2 is directly managing the EC2, selectingthe preferred management path as the indirect management path via thefederated connection between the NM1 and the NM2; d) if the NM2 is notdirectly managing the EC2: i) assuming a reluctantly promoted state atthe NM1 to enable direct management of the EC2 by the NM1; and ii)selecting the preferred management path as the reluctantly promoteddirect management path between the NM1 and the EC2.
 12. A method asclaimed in claim 11, further comprising, if the NM2 is not directlymanaging the EC2, the step of periodically attempting to demote the NM1from the reluctantly promoted state.
 13. A method as claimed in claim12, wherein the step of periodically attempting to demote the NM1comprises the steps of: a) periodically determining if the NM2 hasrecovered direct management of the EC2; and ii) when the NM2 hasrecovered direct management of the EC2: ii) demoting the reluctantlypromoted state of the NM1; and ii) selecting the preferred managementpath as the indirect management path via the federated connectionbetween the NM1 and the NM2.
 14. A method as claimed in claim 11,wherein the step of querying the EC comprises: a) sending a querymessage to the EC2, and receiving a response message from the EC2containing information identifying each network manager logicallyconnected to the EC2 over a direct management path; and 68) selectingthe information identifying the NM2 from among the informationidentifying each network manager logically connected to the EC2 over adirect management path.
 15. A method as claimed in claim 11, wherein thestep of determining if the NM2 is available for communication with theEC2 comprises the steps of: a) sending a connection request message tothe NM2 and waiting for a response message from the MN2; b) if theresponse message is received from the MN2, determining that the NM2 isavailable; and c) otherwise, determining that the NM2 is not available.16. A method as claimed in claim 11, wherein, when the preferredmanagement path is the indirect management path via a federatedconnection, the step of establishing a logical connection over thepreferred management path comprises: a) establishing a federatedconnection between the NM1 and the NM2, the NM1 acting as an indirectclient for the NM2, and the NM2 acting as an indirect server for theNM1; and 69) establishing a logical connection between the NM1 and theEC2 through the NM2 using the federated connection.
 17. A scalablecommunication network having a plurality of element controllers (ECs)adapted to control operations of a respective plurality of networkelements, and two or more network managers (NMs) adapted for managingeach of the element controllers (ECs), the network comprising: a) afirst network manager (NM1) logically connected to a first elementcontroller (EC1) via a direct management path for direct management ofthe EC1 by the NM1; and b) a second network manager (NM2) adapted to: i)dynamically select, from at least two management paths, a preferredmanagement path between the NM2 and the EC1; and 70) establish a logicalconnection between the NM2 and the EC1 over the selected preferredmanagement path to enable management of the EC1 by the NM2.
 18. Ascalable communication network as claimed in claim 17, wherein the atleast two management paths comprise one or more of: an indirectmanagement path via a federated connection between the NM2 and the NM1;and a reluctantly promoted direct management path between the NM2 andthe EC1.
 19. A scalable communication network as claimed in claim 18,wherein the first network manager (NM1) comprises an indirect servermanger (ISM) component adapted to enable a federated connection betweenthe first network manager (NM1) and the second network manager (NM2).20. A scalable communication network as claimed in claim 19, wherein theindirect server manger (ISM) component is further adapted to enable alogical connection between the first element controller (EC1) and thesecond network manager (NM2) through the federated connection.
 21. Ascalable communication network as claimed in claim 18, wherein thesecond network manager (NM2) comprises an indirect client manager (ICM)component adapted to enable management of the first element controller(EC1) using the selected preferred management path.
 22. A scalablecommunication network as claimed in claim 21, wherein the ICM componentis adapted to dynamically select the preferred management path by: a)querying the EC1 to obtain information identifying the NM1 logicallyconnected to the EC1 via a direct management path; b) determining if theNM1 is directly managing the EC1; c) if the NM1 is directly managing theEC1, selecting the preferred management path as the indirect managementpath via the federated connection between the NM2 and the NM1; d) if theNM1 is not directly managing the EC1: i) assuming a reluctantly promotedstate to enable direct management of the EC1 by the NM2; and 73)selecting the preferred management path as the reluctantly promoteddirect management path between the NM2 and the EC1.
 23. A scalablecommunication network as claimed in claim 22, wherein, if the NM1 is notdirectly managing the EC1, the ICM component is adapted to periodicallyattempt to demote the NM2 from the reluctantly promoted state.
 24. Ascalable communication network as claimed in claim 23, wherein the ICMcomponent is adapted to periodically attempt to demote the NM2 by: a)periodically determining if the NM1 has recovered direct management ofthe EC; and b) when the NM1 has recovered direct management of the EC:i) demoting the reluctantly promoted state of the NM2; and 75) selectingthe preferred management path as the indirect management path via thefederated connection between the NM2 and the NM1.
 25. A scalablecommunication network as claimed in claim 17, wherein each elementcontroller comprises a respective collector name server includinginformation identifying each network manager to which the elementcontroller is logically connected over a direct management path.
 26. Ascalable communication network as claimed in claim 25, wherein thecollector name server is responsive to a query from the NM1 to send aresponse message to the NM1 containing the information identifying eachnetwork manager to which the element controller is logically connectedover a direct management path.
 27. A scalable communication network asclaimed in claim 17, wherein each network manager (NM) comprises arespective indirect access database (IAD) including informationrespecting devices to which the network manager can logically connect.28. A scalable communication network as claimed in claim 27, wherein theIAD further comprises information identifying other network managersfrom which connection requests will be accepted to permit indirectmanagement of any element controllers directly managed by the respectivenetwork manager (NM).
 29. A scalable communication network as claimed inclaim 28, wherein the IAD further comprises a list of paths availablefor selection as a preferred management path to enable management of anelement controller.
 30. A self healing communication network in which aplurality of element controllers (ECs) are connected for controllingoperations of a respective plurality of network elements, and two ormore network managers (NMs) are adapted for managing each of the elementcontrollers (ECs), the network comprising: a) a first network manager(NM1) logically connected to a first element controller (EC1) over adirect management path for direct management of the first elementcontroller (EC1); and b) connection means adapted for: i) dynamicallyselecting, from at least two management paths, a preferred managementpath between the EC1 and a second network manager NM2; and 77) establisha logical connection between the NM2 and the EC over the selectedpreferred management path to enable management of the EC1 by the NM2.31. A self healing communication network as claimed in claim 30, whereinthe at least two management paths comprise one or more of: an indirectmanagement path via a federated connection between the NM2 and the NM1;and a reluctantly promoted direct management path between the NM2 andthe EC.
 32. A self healing communication network as claimed in claim 31,wherein the connection means further comprises an indirect server manger(ISM) component operatively connected to the first network manager(NM1), the ISM component being adapted to enable a federated connectionbetween the second network manager (NM2) and the first network manager(NM1).
 33. A self healing communication network as claimed in claim 31,wherein the connection means further comprises an indirect clientmanager (ICM) component operatively connected to the second networkmanager (NM2), the ICM component being adapted to enable management ofthe first element controller (EC1) over the selected preferredmanagement path.
 34. A self healing communication network as claimed inclaim 33, wherein the ICM component is adapted to dynamically select thepreferred management path by: a) querying the EC1 to obtain informationidentifying the NM1 logically connected to the EC1 via a directmanagement path; b) determining if the NM1 is directly managing the EC1;c) if the NM1 is directly managing the EC1, selecting the preferredmanagement path as the indirect management path via a federatedconnection between the NM2 and the NM1; d) if the NM1 is not directlymanaging the EC1: i) assuming a reluctantly promoted state to enabledirect management of the EC1 by the NM2; and ii) selecting the preferredmanagement path as the reluctantly promoted direct management pathbetween the NM2 and the EC1.
 35. A self healing communication network asclaimed in claim 34, wherein, if the NM1 is not directly managing theEC1, the ICM component is adapted to periodically attempt to demote theNM2 from the reluctantly promoted state.
 36. A self healingcommunication network as claimed in claim 35, wherein the ICM componentis adapted to periodically attempt to demote the NM2 by: a) periodicallydetermining if the NM1 has recovered direct management of the EC; and b)when the NM1 has recovered direct management of the EC: i) demoting thereluctantly promoted state of the NM2; and ii) selecting the preferredmanagement path as the indirect management path via the federatedconnection between the NM2 and the NM1.
 37. A self healing communicationnetwork as claimed in claim 30, wherein the connection means comprises acollector name server including information respecting each networkmanager (NM) logically connected to the first element controller (EC1)over a direct management path.
 38. A self healing communication networkas claimed in claim 37, wherein an instance of the collector name serveris operatively connected to the first element controller (EC₁).
 39. Aself healing communication network as claimed in claim 37, wherein theconnection means further comprises an indirect access database (IAD)including information respecting devices to which a respective networkmanager can connect.
 40. A self healing communication network as claimedin claim 39, wherein the IAD further comprises means for identifyingother network managers from which connection requests will be acceptedto permit indirect management of any element controllers directlymanaged by the respective network manager (NM).
 41. A self healingcommunication network as claimed in claim 40, wherein the IAD furthercomprises means for determining management paths available for selectionas the preferred management path to enable management of the elementcontroller.
 42. A self healing communication network as claimed in claim37, wherein the collector name server is responsive to a query from theNM1 to send a response message to the NM1 containing the informationidentifying each network manager to which the element controller islogically connected over a direct management path.
 43. A network manager(NM) for managing a plurality of element controllers (ECs) of acommunication network, the network manager (NM) comprising: a) directconnection means for logically connecting the network manager (NM) to afirst element controller (EC1) over a direct management path for directmanagement of the first element controller (EC1); and b) indirectconnection means adapted for: i) dynamically selecting, from at leasttwo management paths a preferred management path between the NM and asecond element controller EC2; and ii) establishing a logical connectionover the preferred management path to enable management of the (EC2) bythe NM.
 44. A network manager as claimed in claim 43, wherein the atleast two management paths comprise one or more of of: an indirectmanagement path via a federated connection between the NM and a secondnetwork manager (NM2) directly managing the EC2; and a reluctantlypromoted direct management path between the NM and the EC2.
 45. Anetwork manager as claimed in claim 44, wherein the indirect connectionmeans comprises an indirect client manger (ICM) component adapted toenable management of the EC2 by the NM over the preferred managementpath.
 46. A network manager as claimed in claim 45, wherein the ICMcomponent is adapted to dynamically select the preferred management pathby: a) querying the EC2 to obtain information identifying the NM2logically connected to the EC2 over a direct management path; b)determining if the NM2 is directly managing the EC2; c) if the NM2 isdirectly managing the EC2, selecting the preferred management path asthe indirect management path via the federated connection between the NMand the NM2; d) if the NM2 is not directly managing the EC2: i) assuminga reluctantly promoted state to enable direct management of the EC2 bythe NM; and ii) selecting the preferred management path as thereluctantly promoted direct management path between the NM2 and the EC2.47. A network manager as claimed in claim 46, wherein, if the NM2 is notdirectly managing the EC2, the ICM component is adapted to periodicallyattempt to demote the NM from the reluctantly promoted state.
 48. A selfhealing communication network as claimed in claim 47, wherein the ICMcomponent is adapted to periodically attempt to demote the NM by: a)periodically determining if the NM2 has recovered direct management ofthe EC2; and b) when the NM2 has recovered direct management of the EC2:i) demoting the reluctantly promoted state of the NM; and ii) selectingthe preferred management path as the indirect management path via thefederated connection between the NM and the NM2.
 49. A network manageras claimed in claim 44, wherein the indirect connection means furthercomprises an indirect server manager ISM component adapted to enableindirect management of the first element controller (EC1) by anothernetwork manager using an indirect management path via a federatedconnection between the other network manager and the NM.
 50. A networkmanager as claimed in claim 45, wherein the indirect connection meansfurther comprises an indirect access database (IAD) includinginformation respecting devices to which the network manager can connect.51. A network manager as claimed in claim 50, wherein the IAD furthercomprises, in respect of each device to which the network manager canconnect, information respecting a preferred connection path.
 52. Anetwork manager as claimed in claim 51, wherein the IAD furthercomprises means for determining other network managers from whichconnection requests will be accepted to permit indirect management ofany element controllers directly managed by the network manager (NM).